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Preface - Goal 




Standard for describing telemetry and commanding 

Lower cost and increase validation (XML) over traditional formats 

Conceived as universal exchange mechanism between ground 
segment apps (users) that need TLM/CMD descriptions 



. (e.g. native format) 
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Satellite Factory 

Common Formats Facilitate 
Transition to Operations and 
Data Exchange 
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Preface - Brief History and Background 


& 


• XTCE 1.0 published in 2005 (OMG only) 

• XTCE 1.1 published in Oct 2007 (CCSDS and OMG) 

• XTCE 1.1 Green Book - overview, 2007 

• XTCE 1.1 Magenta Books, under review 

- Core — User Guide 

- CCSDS tailoring 

• XTCE 1.2 - 1 st draft review 
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Preface - Applicability 



• XTCE is very flexible 

- Large # of elements and attributes to describe wide range of "blocky data", but... 

• This discussion will be principally oriented towards Packets or Minor Frames 

• Assumes traditional tlm/cmd approach: 

- "bit-packed" data - no markers, metadata, non-self describing entries in data blocks 

- But some format markers (such as CCSDS packet header fields) 

• Oriented towards Exchange 

- Ground applications that either need or produce telemetry and command descriptions 
But are tied to native formats 

I nstead of many- to- many conversion 

Each transfers to XTCE and back, resulting in... 

• More flexibility to mix and match ground apps 

• Economies of scale 

• Avoid proprietary formats 

• Features in XTCE are needed by ground system apps 

- While every feature may not be needed, many features should be needed 
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Chapter 1 - The SpaceSystem 




• The SpaceSystem is the root or the outermost element of any XTCE document 

- Can be used to represent almost any aspect of your architecture: 

- The entire project, a portion of your project, subsystems, etc... 

- Optional child SpaceSystem - build a tree like structure of SpaceSystems 

- Could be used in single spacecraft to entire constellation scenario 


<xtce: SpaceSystem attributes 

<xtce: T elemetryMetaData/ > 
<xtce: Command Meta Data/ > 

<xtce: SpaceSystem attributes/ > 
</x tee: SpaceSystem> 
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Chapter 1 - The SpaceSystem 




<xtce: SpaceSystem name=“MyRoot”> 

<xtce:TelemetryMetaData/> < 

<xtce : Co m m a n d M eta D ata/> 

<xtce:SpaceSystem name=“MySubSys1 ”/> 

<xtce:SpaceSystem name=“MySubSys27> « 

<xtce: SpaceSystem name=“MySubSys3”> 

<xtce:T elemetryMetaData/> 
<xtce:CommandMetaData/> 

<xtce:SpaceSystem name=“MySubSubSys3. 1 7 > 
<xtce : S paceSystem > 

<xtce : S paceSystem > 


Common Tlm/Cmd 


Tlm/Cmd for this sub-sys 


Note: some required attributes or elements not shown for purposes of illustration 
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Chapter 1 - The SpaceSystem 




MyRoot 



MySubSysl 


MySubSys2 MySubSys3 



Any <SpaceSystem> tree-structure is possible 

-- Items defined in one <SpaceSystem> may refer to another using a string pointer (“Ref) 

- “Refs” come in various forms, similar syntax to directory paths 

-- The simplest form is just the name of the item of interest, means local to current <SpaceSystem> or 
any above it 

-- Absolute and relative path are also supported, go to the item the <SpaceSystem> specified 
A single <SpaceSystem> with globally unique names of things is simplest 
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Chapter 1 - The SpaceSystem 




<xtce: SpaceSystem> 

<xtce: T el emetry Meta Data/ > 
<xtce: Command Meta Data/ > 

<xtce: SpaceSystem/ > 

</xtce: SpaceSystem> 


• Each SpaceSystem has a telemetry and command description area 

- Both are optional 

• (a minimally valid XTCE file is a single SpaceSystem and name - more or less) 

- Tel emetryMeta Data - describe telemetry things here 

- CommandMetaData - describe command things here 

- A description in one may refer to a description in the other in which case 

• description is "co-opted" as if it were originally defined on that side 

- The name-space for TelemetryMetaData and CommandMetaData is shared 

• For example a Parameter defined in TelemetryMetaData is visible in CommandMetaData 
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Chapter 1 - Parameters and ParameterTypes 


<xtce: SpaceSystem> 

<xtce:T elemetryMetaData> 
<xtce:ParameterSet/ > 
<xtce: ParameterTypeSet> 

</xtce:TelemetryMetaData> 

<xtce: Command Meta Data/ :> 
<xtce: SpaceSysterrV > 

</ xtceSpaceSystem> 


• Telemetry parameters are defined with elements <Parameter> & <ParameterTypes> 

(There are also command parameters, session or system parameters and derived or pseudo- parameters) 

A parameter HAS A parameterType and some Properties 

ParameterType descriptions may be shared with more than one Parameter 

• Use these to describe the name of a single telemetry item and show its 

Link Data Type -> Conversion -> Host Data Type relationship 
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Chapter 1 - Containers 


0T 


<xtce:TelemetryMetaData> 

<xtce:ParameterSet/> 

srTypeSet/> 

<xtce:ContainerSet> 

<xtce:SequenceContainer/> 

</xtce:ContainerSet> 

</xtce:TelemetryMetaData 


• Use < SequenceContainer> to describe telemetry formats (CCSDS packet, etc...) 

- Specify Sequence of parameters 

• various options to manipulate sequence 

- Optionally EXTEND another container in an inheritance like fashion 

• Use element <BaseContainer> to name the parent container 

• Specify <RestrictionCriteria> to define identifying "keys" and expected values (such as APID=10) 

• Principally a construction mechanism, child inherits certain properties from the parent, mainly its entries 

• And also used to provide the identifying information 

• (CommandContainers and MetaCommand/CommandContainers are similar) 
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Chapter 1 - Command and CommandContainers 


<xtce: SpaceSystem> 

<xtce: T elemetryMetaData/ > 

<xtce:CommandMetaData> 
<xtce:ParameterSet/ > 
<xtce:ParameterTypeSet/ > 
<xtce:ArgumentTypeSet/ > 
<xtce:MetaCommandSet/ > 
<xtce:CommandContainerSet/ > 
</ xtce:CommandMetaData> 
<xtce: SpaceSystenY > 

</xtce: SpaceSystem> 


Put Command related description in <CommandMetaData> 

- Command Parameter and ParameterType 

• Same construction as on telemetry side but some child elements or should be ignored and are probably 
not applicable 

- Argu mentTypeSet - command Arguments are similar to Parameters in constructions 
Command Description in element: <MetaCommand> 

• Included its arguments, local <CommandContainer> (packaging information, verifiers and other 
cmd related items 

Command <Argument> links to <ArgumentType> 
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Chapter 1 - NameReferences 




<SpaceSystem> 

<T elemetryMetaData> 

<ParameterT ypeSet> 

<lntegerParameterType name=“MyType”/> 

</ParameterTypeSet> 

<ParameterSet> 

<Parameter name=“MyParam” parameterType=“MyType”/> 
</ParameterSet> 

</T elemetryMetaData> 

</SpaceSystem> 

• NameReferences (NameRefs or Refs) are string pointers 

Points from one location in an XTCE file to another, perhaps 50 NameRefs at various elements 
Format: {[SpaceSystem name, .y/^temName 

• myParameter 

• /SpaceSystemNamel/SpaceSystemName2/ myParameter 

• . ./SpaceSystemName2/ myParameter 

- The first (plain or unqualified) is not global; refers to local SpaceSystem first or up "the 
SpaceSystem tree" relative to that location 

• Favor relative addressing vs absolute if used 

- Outside of XML parsing unfortunately - you must implement it 

• Careful implementation required for general case 

... (But only one SpaceSystem is easiest, use plain version for everything) 
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Chapter 2 - 

- Describing Telemetry 


<xtce: SpaceSystem> 

<xtce : T el emetry Meta Data > 

<xtce: ParameterTypeSet/ > 
<xtce: ParameterSet> 

</xtce: T elemetryMetaData> 
<xtce: CommandMetaData/ > 
<xtce: SpaceSystem/ > 
</xtce: SpaceSystem> 


www.nasa.gov 


XTCE Tutorial, Manhattan Beach, California, March 3, 2010 


14 


Chapter 2 - ParameterTypes 




<xtce: ParameterTypeSet> 

<xtce: Stri ngParameterT ype/ > 

<xtce: EnumeratedParameterType/> 
<xtce: BinaryParameterType/> 

<xtce: I ntegerParameterType/> 

<xtce: FloatParameterType/> 

<xtce: BooleanParameterType/> 
<xtce: Absol uteTi meParameterT ype/ > 
<xtce: Relati veTi meParameterT ype/ > 
<xtce: ArrayParameterT ype/ > 

<xtce: AggregateParameterT ype/ > 
</xtce: ParameterTypeSet> 


The names represent host side data types 
String, 

Enumerated, 

Binary, 

Integer 

Float 

Boolean 

AbsoluteTime 

RelativeTime 

Array 

Aggregrate (groups other Parameters) 


These data types are what your system will process 
the data encoded on the link into 

Advanced: a ParameterType may optionally inherit 
from another, see the @baseType attribute. Simpler 
implementations can ignore. 
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Chapter 2 - Pattern to (most) ParameterTypes 



Pattern: 

• DataType + (choice of one) DataEncoding 


<xtce: String Pa rameterType> 
<xtce: StringDataEncoding/> 


• DataEncodings describe transmitted 
(link) information 


<xtce: I ntegerDataEncoding/> 
<xtce: FloatDataEncoding/> 


Choice of One * Alarms and various details vary by 
° r ParameterType 

None 


<xtce: BinaryDataEncoding/> 
<xtce: Alarms/ > 


• Likely common combinations of 
ParameterType and DataEncoding choices are 
documented 


</xtce: String Pa rameterType> . Other combos may make sense (mission 

specific), and not strictly speaking illegal at this 
time 
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Chapter 2 - ParameterType Semantics 



• ParameterTypes and their child elements and attributes, taken together, 
represent this relationship between information on the link and ground 


10111010 


Encoded Link 

VpHr/Rnnge 1 

|— — — — — — — n 

v,l C.pUhratinn [ s, 

Host 

At firm 

Data Type 

! Check \ 

J_ Step i 

Data Type 

\ Check 


DgtaEncgding_ 

, StringDataEncoding Raw check only 

-IntegerDataEncoding 
-FlootDotoEncoding 
-BinaryDotaEncoding 


ParqmeterTy^e 

-String 

-Float 

-Integer 

-Enumeration 

-Binary 

-Boolean 

-Time 

- Array , Aggregate 


Missions will likely wish to restrict these various elements and attributes for various ParameterType... 


www.nasa.gov 


XTCE Tutorial, Manhattan Beach, California, March 3, 2010 


17 


Chapter 2 - DataEncodings 




• Four options, various details: 

- StringDataEncoding 

• UTF8 or UTF16 encoded Unicode (UTF-16 big endian) 

• Bit size, various ways 

- I ntegerData Encoding 

• Unsigned or TwosComplement (spelled "Compliment" in XTCE!) 

• Bit size 

• bit/ byte order 

• Various calibrators such as Linear Calibrator or Polynomial Calibrator optional 

- FloatDataEncoding 

• IEEE- 745, Ml L1750A 

• Bit size 

• bit/ byte order 

• Various calibrators such as Linear Calibrator or Polynomial Calibrator optional 

- BinaryDataEncoding 

• Bit size 

• bit/ byte order 

• No cals. . . 

Some additional details left out 
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Chapter 2 - DataEncoding - Examples 


Unsigned int, 32 bits 

<xtce: 1 ntegerDataEncoding sizel nBits= ,, 32"/> 

Two Complement, 8 bits 

<xtce:l ntegerDataEncoding encoding= ,, twosCompl]ment ,, /> 

Float, 32- bit, IEEE- 754 

<xtce: FloatDataEncoding/> 

Unicode String, UTF-16 

<xtce:StringDataEncoding encoding="UTF-16"> 

<!— Example: Length in bits is 11 characters — > 
<!— 16- bits per character — > 

<xtce: Sizel nBits> 

<xtce:Fixed> 

Note: defaults are not shown, the parser 

<xtce: FixedValue>176</xtce: FixedValue> 

should provide it, helps keep the file shorter 

</xtce: Fixed> 


</xtce: Sizel nBits> 
</xtce: StringDataEncoding> 
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Chapter 2 - Telemetry ParameterTypes - Reference 
Diagram 



10111010 


Encoded Link 

>i VpliriRange 1 
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Host 
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Data Type 

Check 

J_ Step i 

Data Type 

\ Check 


DgtaEncgdj nq 

-StringDatoEncoding 

-IntegerDotoEncoding 

-FloatDatoEncoding 

-BinaryDatoEncoding 


ParqmeterTy^e 

-String 

-Float 

-Integer 

-Enumeration 

-Binary 

-Boolean 

-Time 

- Array , Aggregate 
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Chapter 2 - ValidRange Check 



• ValidRange Check 

I ntegerParameterType and FloatParameterType only 


<xtce: ValidRange minlnclusive="0" maxlnclusive="1 00"/> 


Ignore for Telemetry side: 

-lntegerParameterType/@validRangeAppliesToCalibrated=(true | false) 
-FloatParameterType/@validRangeAppliesToCalibrated=(true | false ) 


In essence the ValidRange check for telemetry is assumedjo be on the_RAW_ DataEncoding_ valuer 
the current version ofXTCE Is not cjearon this. 
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Chapter 2 - Telemetry ParameterTypes - 
Reference Diagram 



10111010 


Encoded Link 

VpHr/Rnnge 1 

|— — — — — — — n 
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Host 
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Data Type 

! Check \ 
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Data Type 

\ Check 
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-StringDatoEncoding 
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Chapter 2 - Calibrators 
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• Calibrators are defined in the DataEncoding area 

• A DefaultCalibrator 

- J ust one 

• Or ContextCalibrators 

- Many 

- Conditional “Contexts", user defined (e.g. Mission Phases) 

• We'll look at two common types 

- polynomial (PolynomialCalibrator) 

- line segment (SplineCalibrator) 
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Chapter 2 - Linear Calibrator 


0T 


<xtce:SplineCalibrator> 

<!■ -Forward (regular) calibration --> 
<xtce:Sp!inePoint raw="1 " calibrated-' 10"/> 
<xtce:Sp!inePoint raw="2" calibrated-' 100"/> 
<xtce:Sp!inePoint raw="3" calibrated="500"/> 
</xtce:SplineCalibrator> 


There’s an optional @order attribute in SplinePoint - this is a typo in the Schema, ignore 


But just to be confusing - there’s an optional SplineCalirbator attribute @order which can be 
used to designate higher order splines. However there may need to be more info supplied (in 
Ancillary) to fully describe the details of your spline in the current version of XTCE 
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Chapter 2 - Polynomial Calibrator 


& 


The equation for the calibration is: y = - 0.0048x 2 + 1. 4091 x- 48.886 


<xtce:PolynomialCalibrator> 

< !- Forward (regular) calibration --> 

<xtce: Term exponent="0" coefficient="-48. 886"/> 
<xtce: Term exponent-' 1 " coefficient-' 1 . 409 1 "/> 
<xtce: Term exponent="2" coefficient="-0. 0048"/> 
</xtce:PolynomialCalibrator> 


The number of terms is unlimited in the Schema you may wish to 
restrict this for your mission 


48.886 
1.409 lx 
0.0048X 2 
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Chapter 2 - Telemetry ParameterTypes - 
Reference Diagram 



10111010 


Encoded Link 

VpHr/Rnnge 1 

|— — — — — — — n 

v,l C.pUhratinn [ s, 

Host 

At firm 

Data Type 

! Check \ 

| Step i 

Data Type 

\ Check 


D ataEncodiny 

-StringDatoEncoding 

-IntegerDotaEncoding 

-FloatDotoEncoding 

-BinaryDataEncoding 


ParameterType: 

String, 

Enumerated, 

Binary (catch all), 

Integer 

Float 

Boolean 

AbsoluteTime 

RelativeTime 

Array 

Aggregrate (groups of other Parameters) 


www.nasa.gov 


XTCE Tutorial, Manhattan Beach, California, March 3, 2010 


26 


Chapter 2 - Likely ParameterType/DataEncoding 
Combinations 


ParameterType 

DataEncoding 

Result 

Stri ngParameterType 

StringDataEncoding 

Unicode String encoded as either UTF-8 or UTF-16 

EnumeratedParameterType 

1 ntegerDataEncoding 

LABEL, VALUE pairs 

Bi naryParameterType 

Bi naryParameterType 

Blob data 

1 ntegerParameterType 

1 ntegerDataEncoding 

• Integers of various well known formats (one/ twos 
complement, etc...) 

• Calibrated/ uncalibrated an option 

FloatParameterType 

FloatDataEncoding 

•Floats of well known formats (1 EEE/MI L1750A) 
• Calibrated/ uncalibrated an optiona 

FloatParameterType 

1 ntegerDataEncoding 

•1 nteger counts to units conversion 
• Calibrated 

BooleanParameterType 

1 ntegerDataEncoding 

True/ False 

Absol uteTi meParameterType 

1 ntegerDataEncoding 

•Time, same for RelativeTi meParameterType 

Any of the above 

Bi naryDataEncodi ng 

Format not describable with what is there 

Aggregate or Array ParameterType 

N/A 

These NameReference other ParameterTypes 


Others? May not make sense to some but not illegal! 
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Chapter 2 - Telemetry ParameterTypes - 
Reference Diagram 
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Chapter 2 - Alarms 


& 


• DefaultAlarm and ContextAlarms 

- Default is . . . well the default 

- Contexts - user defined such as mission phase 

• A variety of limit checks are available in XTCE and tuned to their 
ParameterType somewhat: 

- AlarmConditions: check a condition 

- StaticAlarmRanges: compare values against set of ranges 

- ChangeAlarms: Rate or Delta 

Slight variations for String & Enum alarms 


XTCE Alarm Ranges 
(optional) 

Normal - Inside Least Severe 

Range 

WatchRange 

WarningRange 

CriticalRange 

SevereRange 


More severe ranges clip lower ranges 
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Chapter 2 - StaticAlarmRange Example 



<xtce:StaticAtarmRanges> 

<xtce:WatchRange minlnclusive="-2000. 0" maxlnclusive="5000. 0"/> 
<xtce:Se ve re Range minlnclusive= "-5000. 0 " m axlnclusive = "6000. 0 "/ > 
</xtce:StaticAlarmRanges> 

Real Ranges: 

-Green: -2000 .0 > x< 5000.0 - implied 
-Watch: *<= -2000.0 or x>= 5000.0 
-Severe: x<= -5000.0 or x>= 6000.0 



Note: Color designation is not part of XTCE, user dependent 
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Chapter 2 - AlarmConditions 



• Set up conditions for up to five levels 

- The alarm "returns" the highest level triggered 

- Simple single conditions, multiple conditions, boolean expressions, custom algorithms 


<xtce:AlarmConditions> 

< <tce:WarningA > 

<xtce:Comparison parameterRef-'pressureValue" value="100" comparisonOperator="&gt;"/> 
</xtce:WamingAlarm> 

<xtce:CriticalAlarm> 

<xtce:Comparison parameterRef="pressureValve" value="150" comparisonOperator="&gt;7> 
</xtce:CriticalAlarm> 

<xtce:SevereAlarm> 

<xtce:Comparison parameterRef="pressureValve" value="175" comparisonOperator="&gt;7> 
</xtce:SevereAlarm> 

</xtce:AlarmConditions> 
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Chapter 2 - ChangeRateAlarms 




• Similar to the others in terms of ranges but two choices in 
one element. . . 


Rate of Change 


Delta Change 


Attribute 

Value 

Attribute 

Value 

@changeType 

changePerSecond 

@changeType 

changePerSample 

@changeBasis 

absoluteChange | 

percentageChange 

@changeBasis 

absoluteChange | 

percentageChange 

@spanOfl nterestl nSamples 

ignore 

@spanOfl nterestl nSamples 

1 or more 

@spanOfl nterestl nSeconds 

1 or more 

@spaceOfl nterestl nSeconds 

ignore 


• Either a 1 st derivative alarm that is either with respect to time or with respect to samples 
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Chapter 2 - ParameterType Examples 



IntegerParameterType 


<xtce: IntegerParameterType signed= "false " name= ‘‘MySample Type "> 
<xtce:UnitSet/> 

<xtce:lntegerDataEncoding slzelnBlts= "32"/> 

<xtce:DefaultAlarm> 

<xtce:StaticAlarmRanges> 

<xtce:WatchRange minlnclusive="-2000. 0" maxlnclusive="5000. 0"/> 
<xtce:WarningRange minlnclusive="-5000. 0" maxlnclusive="6000. 0"/> 
</xtce:StaticA/armRanges> 

</xtce:DefaultAlarm> 

</xtce:!ntegerParameterType> 
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Chapter 2 - ParameterType Examples 
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FloatParameterType 


<xtce:FloatParameterType size/nB/ts= "64 " name= ‘‘DecaySensorType "> 
<xtce:UnitSet> 

<xtce:Unit description= "Bq ">Becquerel</xtce:Unit> 

</xtce:UnitSet> 

<xtce:lntegerDataEncoding sizelnBits="1 6" encoding="twosCompHment"> 
<xtce:DefaultCalibrator> 

<xtce:SplineCalibrator> 

<xtce:SplinePoint raw="-32768. 0" calibrated="0. 0"/> 
<xtce:SplinePoint raw="0. 0" calibrated="5.0"/> 

<xtce:SplinePoint raw="32767. 0" calibrated="20. 0"/> 
</xtce:SplineCalibrator> 

</xtce:DefaultCalibrator> 

</xtce:lntegerDataEncoding> 

</xtce:F!oatParameterType> 
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Chapter 2 - Describing Telemetry Items 



<xtce: SpaceSystem> 

<xtce:TelemetryMetaData> 

< xtce : Pa ra meterTy peSet/ > 

<xtce: ParameterSet> 

</xtce:TelemetryMetaData> 
<xtce: Command Meta Data/ > 
<xtce: SpaceSystem/ > 

</xtce: SpaceSystem> 
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Chapter 2 - A Parameter has a ParameterType 



• Parameter 

• Holds a name of a telemetry item — "BAV10089-B" 

• And a NameRef - to a ParameterType 

• And an optional "ParameterProperties/@dataSource" attribute 

• Telemetered (default - cmd side ignore) 

• Derived, local, etc... 

• ParameterTypes may be shared by different Parameters... 

• An easier implementation approach is to have a one to one mapping between every Parameter and a 
ParameterType definition. 


<xtce : ParameterT y peSet> 

<xtce: I ntegerParameterT y pe name=“My ParameterT ype”> 
<xtce:lntegerDataEncoding/> 

<xtce:lntegerParameterType/> 

</xtce : ParameterT y peSet> 

<xtce:ParameterSet> 

<xtce: Parameter name=“BAV10089-B” parameterTypeRef=“MyParameterType’7> 
</xtce:ParameterSet> 
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Chapter 2 - Session or System Variables 
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• To define a variable supplied by the system 

- Simply leave off the DataEncoding in ParameterType 

- And then make Parameter that refers to it 

- The assumption is that somehow the system will supply the state of 
the variable 

- XTCE does not define how this is done, it's just a representation of it 

- Session variables often seem to be useful in a Comparison, where 
the information is held outside the all the descriptions in the file... 

<xtce: String ParameterType name="HostNameType"> 
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Chapter 3 - SequenceContainers 



<xtce: SpaceSystem> 

<xtce:TelemetryMetaData> 
<xtce:ParameterTypeSet/ > 
<xtce: ParameterSet/ > 

<xtce:ContainerSet/ > 

</xtce:TelemetryMetaData> 
<xtce: CommandMetaData/ > 
<xtce: SpaceSysterrV > 

</xtce: SpaceSystem> 
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Chapter 3 - SequnceContainers 


• Use to represent “memory layout" of Parameters (e.g. a packet or 
minor frame) 

- EntryList specifies content and layout: 

• Default: items are "packed” back to back 

• Width taken from ParameterType 

(look up Parameter, then its ParameterType, then ParameterType's Encoding, then the sizel nBits in the 
Encoding) 

- Element: <SequenceContainer> 

• Very general, may refer to other SeqContainers, Parameters 


<SequenceContainer name= "MyDataB/ock"> 
<EntryList> 

<ParameterRef Entry parameterRef=“Pl "/> 
<ParameterRef Entry parameterRef="P27> 
<ParameterRef Entry parameterRef=“P37> 
</EntryList> 

</SequenceContainer> 
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Chapter 3 - Entry Addressing 
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• Location of the entry is an integer value referenced from: 

- The end of the previous entry to the start of This Entry (default) 

- The start of the container to the start of This Entry (containerStart) 

- The end of the container to the end of This Entry (containerEnd) 

- The start of the next entry to the end? of this entry ( nextEntry) 


containerEnd 
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Chapter 3 - Containers - EntryList Options 


& 


• By default EntryList assumes items are “packed" 

- this is the simplest form and easiest to implement 

• But there are several ways to modify an Entry 

Location 

Condition to include it 
Repeats 

<xtce:EntryList> 

<xtce:ParameterRefEntry parameterRef=“Parameter1"> 

<xtce:LocationlnContainerlnBits referenceLocation="containerStart"> 
<xtce:FixedValue>0<xtce: Fixed Value> 

</xtce: Location I nContainerl n Bits> 

</xtce:ParameterRefEntry> 

<xtce:ParameterRefEntry parameterRef=“OptionalParameter"> 
<xtce:lncludeCondition> 

<xtce: Comparison parameterRef-'statusCheck" value="17> 
</xtce:lncludeCondition> 

</xtce:ParameterRefEntry> 

</xtce: Entry List> 


www.nasa.gov 


XTCE Tutorial, Manhattan Beach, California, March 3, 2010 


41 


Chapter 3 - Simple Example 



<xtce : ParameterT ypeSet> 

<xtce:lntegerParameterType name=“MyParameterType”/> 

</xtce : ParameterT y peSet> 

<xtce:ParameterSet> 

<xtce: Parameter name=“MyParameter” parameterTypeRef=“MyParameterType’7> 
</xtce:ParameterSet> 

<xtce:SequenceContainer name=“MyPacket”> 

<xtce: Entry List> 

<xtce:ParameterRefEntry parameterRef=“MyParameter7> 
<xtce:ContainerRefEntry containerRef=“OtherContainer7> 

<xtce: Entry List> 

</xtce:SequenceContainer> 

<xtce:SequenceContainer name=“OtherContainer”> 

<xtce: Entry List> 

<xtce:ParameterRefEntry parameterRef=“IParameter27> 

<xtce: Entry List> 

</xtce:SequenceContainer> 
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Chapter 3 - Container I nheritance 


• Use Container I nheritance to add identifying “keys" to a full description 

keys are identifying locations in the bit-stream, like CCSDS VCI D, API D, packet length or 
format id, minor frame number 

- BaseContainer child element 

• Supply the Parent or "Super" Container Ref 

• Supply "Constraints" - a set of conditions that must be true for this description 

- Conditions are usually Parameters in the Parent Container 

- The condition Parameters are probably I DENTI FYI NG areas of a packet/minor frame: 

» Ex. CCSDS Land: 

» API D 

» Packet Length 

» SCI D, VCI D (note: these are not in packet header - try session variables!) 

• Somewhat like class inheritance but more of a construction technique 

- You do get to say this container I S A that container 

- But instead of method overloading the EntryList of the parent is added to the child's 

- And constraints (RestrictionCriteria) are defined, usually interpreted as identifying keys 
in the bit- stream 
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Chapter 3 - Container I nheritance in Pictures 



MyPacket 


-Abstract 
-Entries 
—Header Fields 
—APiD, Length, etc... 


identifying Areas: 
- APiD, Length 
- SC/D. VC/D 


-Entries 

-Packet parameters 



addresses 


Conceptually 
entries of both 
form a whole 


The constraints allow one to match incoming bits with 
these descriptions - whether literally or conceptually. 
Identifying areas and value for that particular description. 
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Chapter 3 -Telemetry Packet Description - 


MyPacket 



The XTCE constructions: 


<xtce:SequenceContainer name=“MyFormat” abstract=“true”> 
<xtce:EntryList> 

<xtce:ParameterEntryRefparameterRef=“APID> 

<xtce:ParameterEntryRef parameterRef= “L EN> 
</xtce:EntryList> 

</xtce:SequenceContainer> 

<xtce:SequenceContainer name=“MyPacket> 

<xtce:EntryList> 

<xtce:ParameterEntryRefparameterRef-P 1 ”> 
<xtce:ParameterEntryRef parameterRef=“P2”> 
<xtce:ParameterEntryRef parameterRef= “P3 ”> 
</xtce:EntryList> 

<xtce:BaseContainercontainerRef=“MyFormatPacket”> 

<xtce:RestrictionCriteria> 

<xtce:ComparisonList> 

<xtce:Comparison parameterRef=“APID" value=“100”/> 
<xtce:Comparison parameterRef- “L EN" value=“300”/> 
<xtce:Comparison parameterRef= “S C ID" value-' 154”/> 
<xtce:Comparison parameterRef-'VCID" value=“3”/> 
</xtce:RestrictionCriteria> 

</xtce:BaseContainer> 

</xtce:SequenceContainer> 


My Format IS A SequenceContainer 

t 

MyPacket IS A My Form at 


Conceptual Result 

<MyPacket> 

<Entries> 

<APID/> 

<LEN/> 

<P1/> 

<P2/> 

<P3/> 

<When> 

<APID==100/> 

<LEN==300/> 

<SCID==154/> 

<VCID==3/> 

</When> 

</Entries> 

</MyPacket> 


Identifying Constraints 


NOTE: SCID and VCID are Session 
Variables, supplied by the System 
in this construction - NOT SHOWN 
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Chapter 4 - Commanding 



<xtce: SpaceSystem> 

<xtce:TelemetryMetaData> 

<xtce: ParameterTypeSet/ > 
< xtce : Pa ra meterSet/ > 
<xtce:ContainerSet/ > 

</xtce:TelemetryMetaData> 

<xtce:CommandMetaData/ > 

<xtce: SpaceSystem/ > 

</xtce: SpaceSystem> 
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Chapter 4 - CommandMetaData 




Command Descriptions 


• Describes 

- Command and args 

- The Command Packets (or minor frames) 

- Command Parameters 

- Various other aspects of Commanding - verification, etc... 

• Shares some schema- types with Telemetry Meta Data 

- ParameterSet and ParameterTypeSet are exactly the same 

- ArgumentTypeSet is similar to ParameterTypeSet 

- CommandContainerSet is the same as ContainerSet 

• This section then will focus on the differences between the telemetry 
and command side in XTCE 

- Many construction similar to telemetry but difference highlighted 

- Even same XML construction may have a slightly different meaning 
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Chapter 4 - Major CommandMetaData Elements 


& 


<xtce:SpaceSystem> 

<xtce: TelemetryMetaData> 
<xtce:ParameterTypeSet/> 
<xtce:ParameterSet/> 
<xtce:ContainerSet/> 

</xtce: Te!emetryMetaData> 

<xtce:CommandMetaData> 

<xtce:ParameterTypeSet/> 

<xtce:ParameterSet/> 

<xtce:ArgumentTypeSet/> 

<xtce:MetaCommandSet/> 

<xtce:CommandContainerSet/> 

</xtce:CommandMetaData> 

</xtce:SpaceSystem> 
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Chapter 4 - Command ParameterTypes and 
Arg u mentT y pes 



• Command ParameterTypes use the same Schema-types as Telemetry ParameterTypes 

They look identical 

• ArgumentTypes are similar in construction to Telemetry ParmeterType as well 

But they lack alarms (Command ParameterType probably should too) 

• Relationship of chi Id- elements in Type has slightly different meaning: 

- Order is interpreted differently than telemetry - calibrators are "reverse” (aka raw to units) 

- Valid range check may occur two places depending on @validRangeAppliesToCalibrated value 


■Argl” 


Host 

Data Type 


Vah'dRange Calibration 

L - Check #1_ _ , , Step_ 




VaiidRange 
Check #2 


ParameterType 


DataEncodinci 


- String 

-Float 

-Integer 


-StringDataEncoding 

-IntegerDataEncoding 

-FloatDataEncoding 

-BinaryDataEncoding 


-Enumeration 


-Binary 

-Time 


-Array/Aggregate 


Generally the various accepted combinations Type/ Data Encoding are the same for Telemetry ParameterTypes 
VaiidRange is slightly different, and no alarms should be specified 
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Chapter 4 - CommandMetaData 
Parameters and Arguments 



<xtce:SpaceSystem> 

<xtce: TelemetryMetaData> 
<xtce:ParameterTypeSet/> 
<xtce:ParameterSet/> 
<xtce:ContainerSet/> 

</xtce: Te/emetryMetaData> 
<xtce:CommandMetaData> 
<xtce:ParameterTypeSet/> 
<xtce:ParameterSet/> 
<xtce:ArgumentTypeSet/> 
<xtce:MetaCommandSet> 
<xtce:MetaCommand> 
<xtce:ArgumentList/> 
</xtce:MetaCommand> 
</xtce:MetaCommandSet> 
<xtce:CommandContainerSet/> 
</xtce:CommandMetaData> 
</xtce:SpaceSystem> 
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Chapter 4 - Command Parameters vs Arguments 


& 


• Command Parameters and Arguments are very similar but have a 
different meaning: 

- Command parameter values would be supplied by the system or their value 
specified in a RestrictionCriteria 

- Arguments are supplied by the user 

- Example: 

• A checksum in a command packet is probably a good candidate for 
command parameter, the user will never see it or even know it is there 

- Arguments are defined local to a Metacommand 

• Other than this the two are not that different 

- Arguments Ref ArgumentTypes, Parameters Ref ParameterTypes 

- And they are constructed from closely related Schema Types 
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Chapter 4 - Context Diagram 
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■Argl" 

Host 

$} VatidRange 1 

|— — — — — — — n 

_>! Calibration \ — > 

Encoded Link 

— VaiidRange 


Data Type 

Check #1 

| Step i 

Data Type 

Check #2 


Pammeteijyge Numerics only 

-String 

-Float 

-Integer 

-Enumeration 

-Binary 

-Time 

-Array/Aggregate 


Numerics only 

DotaEncodinq 

-StringDataEncoding 

-IntegerDataEncoding 

-FloatDataEncoding 

-BinaryDataEncoding 
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Chapter 4 - ValidRange in Commanding 


& 


• ValidRange in Commanding 

- Unlike Telemetry — can be set to apply BEFORE the command or 
AFTER the command (but not both) 

• BEFORE 

- leave attribute validRangeAppliesToCalibrated true (default) 

• AFTER 

- set attribute validRangeAppliesToCalibrated to false 
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Chapter 4 - CommandMetaData Describing 
Commands 



<xtce:SpaceSystem> 

<xtce: TelemetryMetaData> 
<xtce:ParameterTypeSet/> 
<xtce:ParameterSet/> 
<xtce:ContainerSet/> 

</xtce: Te!emetryMetaData> 
<xtce:CommandMetaData> 
<xtce:ParameterTypeSet/> 
<xtce:ParameterSet/> 
<xtce:ArgumentTypeSet/> 
<xtce:MetaCommandSet> 
<xtce:MetaCommand> 
<xtce:ArgumentList/> 
<xtce:CommandContainer> 
</xtce:MetaCommand> 
</xtce:MetaCommandSet> 
<xtce:CommandContainerSet/> 
</xtce:CommandMetaData> 
</xtce:SpaceSystem> 


MetaCommand/CommandContainer has a LOCAL CommandContainer for Commands 
• Build Command Packets here! 
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Chapter 4 - Describing Commands and Command 
Packets w/ the Metacommand Element 



• Use the Metacommand element to describe Commands 

- Supply Command Arguments 

- A local Container for their Packets (or minor frame) 

- Add any Verifiers, I nterlock, Priority, various constraints, side effects 

- Optional use Metacommand I nheritance to build up the Command 

• Similar to Container I nheritance 

• Use its local Metacommand/ CommandContainer to build its 
Packet (or Minor Frame) 

- Reference Command Parameters 

- Reference Command Arguments 

- And it may Reference other CommandContainers (CommandContainerSet) 

- Also has I nheritance Mechanism similar to Container I nheritance 
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Chapter 4 - Command I nheritance 




• A Metacommand may EXTEND another 

- One Command may EXTEND another 

- BaseMetaCommand 

• Give the Ref of the Metacommand being extended 

• The extending command can add arguments 

- 1 1 gets any Parent arguments and adds its own 

• Or it can set arguments in the Parent's Command 

- Metacommand/ BaseMetaCommand/ ArgumentAssigmentList 


Example 
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Chapter 4 - Command I nheritance in XTCE 



<xtce:MetaCommand name=“PowerCommand abstract="true"> 

<xtce:ArgumentList> 

<xtce: Argument name=“SubSystemName" argumentTypeRef=“SubSysEnumType"/> 

<xtce: Argument name=“DeviceName" argumentTypeRef=“DeviceEnumType7> 

<xtce: Argument name=“State" argumentTypeRef=“StateEnumType"/> 

</xtce:ArgumentList> 

<xtce:CommandContainer/> <!- details left out --> 

</xtce:MetaCommand> 

<xtce:MetaCommand name=“HeaterOn"> 

<xtce:ArgumentList> 

<Argument name=“TargetTemperature argumentTypeRef=“FloatType"/> 

</xtce:ArgumentList> 

<xtce:BaseMetaCommand metaCommandRef=“PowerCommand”> 

<xtce:ArgumentAssignmentList> 

<xtce:ArgumentAssignment argumentName-'SubSystemName" argumentValue=“ThermalControl7> 
<xtce:ArgumentAssignment argumentName="DeviceName" argumentValue=“Heater1"/> 
<xtce:ArgumentAssignment argumentName="State" argumentValue=“ON7> 
</xtce:ArgumentAssignmentList> 

</xtce:BaseMetaCommand> 

<xtce:CommandContainer/> 

</xtce:MetaCommand> 

<xtce:MetaCommand name=“HeaterOfT'> 

<xtce:BaseMetaCommand metaCommandRef=“PowerCommand7> 

<xtce:ArgumentAssignmentl_ist> 

<xtce:ArgumentAssignment argumentName="SubSystemName" argumentValue=“ThermalControl"/> 
<xtce:ArgumentAssignment argumentName-'DeviceName" argumentValue=“Heater1 "/> 
<xtce:ArgumentAssignment argumentName="State" argumentValue=“OFF7> 

</xtce:ArgumentAssignmentList> 

</xtce:BaseMetaCommand> 

<xtce:CommandContainer/> 

</xtce:MetaCommand> 


PowerCommand 
-Argl: SubSystemName 
-Arg2: DeviceName 
-Arg3: State {ON/OFF} 


7 \ 


HeaterOn 

-Argl : SubSystemName=ThermalControl 
-Arg2: DeviceName=Heater1 
-Arg3: State=ON 

-Arg4: TargetTemperature {Fahrenheit} 


HeaterOff 

-Argl : SubSystemName=ThermalControl 
-Arg2: DeviceName=Heater1 
-Arg3: State=OFF 
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Chapter 4 - Metacommand's CommandContainer 




• Metacommand/ CommandContainer 

- Similar to the other Containers but not exactly the same 

• It has a FixedValueEntry to hard code a value 

• 1 1 has an ArgumentRefEntry for Arguments 

(and ArrayArgument and AggrateArgument) 

• It has a BaseContainer but its RestrictionCriteria is optional 

• It has no abstract attribute either! 

• Use it to build the Packet or Minor Frame associated with the 
Metacommand, the EntryList can have: 

- ParameterRefEntry and its various forms 

- ArgumentRefEntry, ArgumentArrayRefEntry, ArgumentAggregateRefEntry 

- FixeValueEntry 

- ContainerRef Entry and its various forms 

• Don't Ref another MetaCommand/Container 

• Instead Ref in CommandContainerSet! 
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Chapter 4 - Metacommand's CommandContainer in 
XTCE 



<xtce: Metacommand name=“PowerCommand abstract="true"> 
<xtce:ArgumentList> 

<xtce:Argument name=“SubSystemName" argumentTypeRef=“SubSysEnumType"/> 
<xtce:Argument name=“DeviceName" argumentTypeRef=“DeviceEnumType"/> 
<xtce:Argument name=“State" argumentTypeRef=“StateEnumType"/> 
</xtce:ArgumentList> 

<xtce:CommandContainer name=“PowerCommandPacket”> 

<xtce:EntryList> 

<xtce:FixedValueEntry binaryValue=“00a0" sizelnBits="16"/> 
<xtce:ParameterRefEntry parameterRef="CheckSum"/> 
<xtce:ArgumentRefEntry argumentRef="SubSystemName7> 
<xtce:ArgumentRefEntry argumentRef="DeviceName"/> 
<xtce:ArgumentRefEntry argumentRef="State"/> 

</xtce:EntryList> 

</xtce:CommandContainer> 

</xtce:MetaCommand> 





Packet name 


“Opcode” 


Check sum, calculated 
by the system, inserted here 
before uplink 


The arguments - order 
does not have to match 
ArgumentList but they should 
all be here... 
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Chapter 4 - Metacommand 
CommandContainer Inheritance 



• A Metacommand/ CommandContainer may EXTEND another 

- This typically occurs if you are using Metacommand I nheritance 

- Similar to Container inheritance in the rest of XTCE 

- But . . . RestrictionCriteria is optional 

- Must EXPLICITLY set BaseContainer (XTCE's syntax) 

- That is - the Metacommand/ CommandContainer/ BaseContainer to 
the Parent's Metacommand/ CommandContainer 

• (easier to visualize than explain) 
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Chapter 4 - Metacommand 
CommandContainer I nheritance in XTCE 



“Is A” 


<xtce:MetaCommand name=“PowerCommand abstract="true"> 

<xtce:ArgumentList> 

<xtce:Argument name=“SubSystemName" argumentTypeRef=“SubSysEnumType"/> 

<xtce:Argument name=“DeviceName" argumentTypeRef=“DeviceEnumType"/> 

<xtce:Argument name=“State" argumentTypeRef=“StateEnumType"/> 

</xtce:ArgumentList> 

<xtce:CommandContainer name=“PowerCommandPacket”> 

<xtce:EntryList> 

<xtce:FixedValueEntry binaryValue=“00a0" sizelnBits="16'7> <!- opcode --> 
<xtce:ArgumentRefEntry SubSystemName, DeviceName, State/> <!- illustrative --> 
</xtce:EntryList> 

</xtce:CommandContainer> 

</xtce:MetaCommand> 

<xtce:MetaCommand name=“HeaterOn"> 

<xtce:Argumentl_ist> 

<Argument name=“TargetTemperature" argumentTypeRef=“FloatType"/> 

</xtce:ArgumentList> 

<xtce:BaseMetaCommand metaCommandRef=“PowerCommand”> 

<xtce:ArgumentAssignmentList> 

<xtce:ArgumentAssignment argumentName="SubSystemName" argumentValue=“ThermalControl7> 
<xtce:ArgumentAssignment argumentName="DeviceName" argumentValue=“Heater1 "/> 
<xtce:ArgumentAssignment argumentName="State" argumentValue=“ON7> 
</xtce:ArgumentAssignmentList> 

</xtce:BaseMetaCommand> 

<xtce:CommandContainer name=“HeaterOnPacket”> 

<xtce:EntryList/> 

<xtce:BaseContainer containerRef="PowerCommandPacket7> 

</xtce:CommandContainer> 

</xtce:MetaCommand> 


PowerCommand 

Cmd 


“Has A” 


PowerCommand 

Packet 




HeaterOn Cmd 


“Has A” 


HeaterOnPacket 
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Chapter 4 - Metacommand CommandContainer 
Inheritance in XTCE w/RestrictionCriteria 



<xtce: Metacommand name=“PowerCommand abstract="true"> 

<xtce:ArgumentList/> <!-- args removed for illustrative purposes --> 
<xtce:CommandContainer name=“PowerCommandPacket”> 
<xtce:EntryList> 

<xtce:ParameterRefEntry parameterRef=“OpCode7> 

<!-- other entries not shown --> 

</xtce:EntryList> 

</xtce:CommandContainer> 

</xtce:MetaCommand> 


System supplies the value 
for OpCode... 


<xtce:MetaCommand name=“HeaterOn"> 

<xtce:ArgumentList> 

<Argument name=“TemperatureCutoff' argumentTypeRef=“FloatType"/> 

</xtce:ArgumentList> 

<xtce:BaseMetaCommand metacommand Ref=“PowerCommand”> 

<xtce:ArgumentAssignmentList/> <!-- arg assignments removed for illustrative purposes --> 
</xtce:BaseMetaCommand> 

<xtce:CommandContainer name=“HeaterOnPacket”> 

<xtce:EntryList/> <!-- other entries not shown --> 

<xtce:BaseContainer containerRef="PowerCommandPacket"> 

<xtce:RestrictionCriteria> 

<xtce:Comparison parameterRef=“OpCode” value=“00a07> < 

</xtce: RestrictionCriteria> 

</xtce:BaseContainer> 

</xtce:CommandContainer> Simple constraints of the st V le “Parameter == value” could be 

P automatically processed to essentially inform the system the values that 

</xtce. MetaCommand> MUST be supplied in the named parameters. You are encouraged to stick 

with that form for this reason but this is not required. 


But checks the value 
here in this constraint. 
?Opcode == OxaO? 
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Chapter 4 - Metacommand and 
Metacommand/ CommandContainer I nheritance 
Sum mary 


& 


< <MetaCommand> > 
BasicCommand 

<<CommandContainer>> 

BasicCommandPacket 




/ , \ 


\ 




(Constraints - optional ) 


< < MetaCommand> > 
MyCmd 


< <CommandContainer> > 
MyCmd Packet 


A Metacommand may EXTEND another: MyCmd extends BasicCommand above 
Their local CommandContainers extend each other: MyCmdPacket extends BasicCommandPacket 
• Constraints are optional here 
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Chapter 4 - Commanding: Other Items 


& 


• Other commanding items in Metacommand: 

- TransmissionConstraint - <TransmissionConstraintList> 

• Check cmd can be run 

- I mplied blockage if constraints fail 

- Significance - <DefaultSignificance>, <ContextSignificanceList> 

• Permission/ confirmations 

- I nterlock 

• Constraints on the next command 

- Verification — <VerifierSet> 

• Variety of command verification by stages (Command Complete) 

- Side Effects - <ParameterToSetList> 

• Side effects after command sent 

- E.g. Command Counter, etc... 

- Suspend Alarms until... <ParameterToSuspendAlarmsSet> 

• Suspend named parameters while cmd takes effect 
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Chapter 4 - CommandContainerSet 




<xtce:SpaceSystem> 

<xtce: TelemetryMetaData> 
<xtce:ParameterTypeSet/> 
<xtce:ParameterSet/> 
<xtce:ContainerSet/> 

</xtce: Te!emetryMetaData> 
<xtce:CommandMetaData> 
<xtce:ParameterTypeSet/> 
<xtce:ParameterSet/> 
<xtce:ArgumentTypeSet/> 
<xtce:MetaCommandSet> 
<xtce:MetaCommand> 
<xtce:ArgumentList/> 
<xtce:CommandContainer> 
</xtce:MetaCommand> 
</xtce:MetaCommandSet> 
<xtce:CommandContainerSet/> 
</xtce:CommandMetaData> 
</xtce:SpaceSystem> 


CommandContainerSet is NOT the same thing as MetaCommand/CommandContainer 
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Chapter 4 - CommandContainerSet 



• Built using the same XTCE Schema-types as ContainerSet in Tel emetryMeta Data. . . 

• Generally meant to be used as the "pieces/ parts" of 
Metacommand/ CommandContai ners 

- Chunks of command parameters that repeat or reused by various commands 

• A "has a" relationship 



{Constraints} 


Has A 



For example - perhaps a Command Packet has an optional secondary header 
-Constraint: Secondary Header Flag must be 1 
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Chapter 5 - The Forgotten Elements 


& 


• Lesser used major elements include: 

- Tel emetry Meta Data/ MessageSet 

- StreamSet 

- AlgorithmSet 

- ServiceSet 
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Chapter 5 - MessageSet 




• Deprecated. . . 

• Essentially an alternative way to build a Packet or Minor 
Frame. . . 

- A purely “HAS A" relationship to Containers 

- Retained from an earlier version of XTCE 
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Chapter 5 - StreamSet - Streams 


& 


• A set of elements to describe aspects of "bit streams" 

- Possibly could be used for portions of frame description, etc... 

• May be included in containers directly 

- Perhaps a special “sub-stream" in a container 

• CCSDS - not quite enough elements to FULLY describe the "CCSDS 
stack" from the frame-sync to packets 

- Lacks RS encoding info for example (although one could use the 
'CustomStream') 

- Generally focus on packet descriptions and leave the FEP for others 

• FixedFrameStreams or VariableFrameStreams reference a top level 
abstract container 

• SequenceContainer identification techniques will determine the specific container 

• Or links to a service 

- Services are abstractions, perhaps a service has certain streams within it... 
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Chapter 5 - AlgorithmSet 




• Used to describe algorithms used in your tlm/cmd 
processing 

- Many options - from actually including code text, to simply the name 
of a function... 

• Two forms: 

- Custom: functions, methods, procedures... 

- Math: equations using postfix notation... 

• Usually define a trigger' that indicates when the algorithm 
should be invoked 
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Chapter 5 - Services 



• An abstraction - groups "logically like" Containers 

• For example: 

- Suppose your mission splits its functionality across multiple CCSDS 
Virtual Channels 

- Each Channel may represent a "service" 

- A Service element could be defined and the list of Containers for 
each API D in the service (VCI D) added 

• Options: 

- point to the "super container" per channel 

- Point to each "final" packet container 

- Point to all the containers making up packets on those channels... 

- Etc...? 

- Totally user defined. . . 
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Chapter 6 - Forms of XTCE I mplementations 




• There are three ways XTCE has been suggested to be used: 

#1 - the exchange form, as it was originally was intended 
#2 - the central repository form 

- A central information database (repository) scenario 
- where it and perhaps other form of info are process in a variety of ways to produce "products" such as: 

• Flight software constructs 

• TLM & CMD databases 

• Documentation 

#3 - the native form, in which it becomes directly part of a tool-chain 

• The first form is by far and away the most popular 

The second form has been proposed and explored by at least two missions 
The third form has never been done 

• I n terms of the first form, it has been prototyped by at least the following: 

NASA-GSFC, and various other NASA centers 
ESA & Norwegian contractors for ESA 

French Space Agency, Russian Space Agency, Germany Space Agency, EDS 
ORS (USAF) 

• It has been used in one mission for DARPA 

Orbital Express (two satellites) 

• It has two vendors (see GovSat for more coming online this year) - Harris OS/ Comet, GMV Archiva 
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Chapter 6 - I mplementing XTCE 


How to a build a very general XTCE parser 

• Step #1 

Validate using XML validation against the official XTCE1.1 Schema 
Bring XML into internal program "model" of class objects 

• Step #2 

Check for duplicate names (@names) by major element in all SpaceSystem, note that Telemetry and Command 
side often form one "namespace" in XTCE for this purpose 

• Step #3 

Resolve all NameReferences so that the actual item being referred to is an object 
Note any "dangling" Refs (Refs that go to no location) 

Check that Refs are by 'Type" correctly, for example a ParameterRef to a ParameterType is indeed to a 
ParameterType, etc... 

Check for loops in the Refs 

See XTCE appinfo element (in the schema text), has additional validity checks that cannot be checked by the 
parser; written in human readable form 

• Step #4 

Implement XTCE's inheritance model for types, containers and commands (hold inheritance relationships in some 
easy to traverse data structure that tracks the parent and child relationships) 

• Step #5 

Match up any enumerations and enumeration alarms (verify the label specified is in the enumeration definition), 
match any initialValue with labels defined (doing this may mean looking in the parent type if there is one) 

• You are now ready to process the information in a variety of ways . . . OR 
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Chapter 6 - I mplementing XTCE 2 




• A simplified XTCE parser can be implemented by outlawing the portions of XTCE that your 
mission is just not going to use AND the forms that are hard to implement 

• The biggest areas of difficulty for most are generalized NameReferences, SpaceSystem 
trees, and any form of inheritance 

• Certain concrete steps can make your job much easier: 

• Step #1 

Removing the SpaceSystem tree hierarchy immediately simplifies the NameReferences as only the simplest form 
of NameReference is necessary - just the name of the item is sufficient 

This implies that the @name things are unique per file at the very least 

• Step #2 

Limit inheritance by selecting "patterns" for commands and tlm that will describe all your packets or minor frames 

Often only one or two levels of inheritance is needed to describe all your content, headers and so forth can be 
placed in parent containers that don't necessarily have even be processed by your software, as you may well know 
what the content should be. . . 

• These two steps alone can vastly simplify an XTCE implementation, while more 
general implementations are desirable, the initiate may find the simpler 
approach is either entirely enough for the needs or at least a good place to start 
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Chapter 6 - Steps to Successfully Using 
XTCE in Exchange 



• Step #1 - Enforce the use of XTCE within project 

• Step #2 - Capture in a "rule book" TLM/CMD aspects for your mission: 

- Naming conventions 

- TLM/CMD format ( "CCSDS Packet", etc. . .) 

- Supported Data Types in TLM/CMD (Ml L-1750A, etc...) 

- Time codes 

- Hardware dependencies (bit/byte order) 

- Limits, calibrators and phasing features (3 levels, 5 term polys, 4 phases) 

- Commanding aspects such validation and so forth... 

• Step #3 - Map rules to XTCE and develop "XTCE rule validation tool" to enforce them 

must parse against XTCE 1.1 Schema AND meet rules 

• Step #4 - Distribute rule guide and tool within project 

• Step #5 - I mport/Export developed to/from each team member's format following rules 

• Check any files with the "rule tool" 

=> A lot of this is upfront planning the customer (probably) to do. . . 

=> I ts benefits accrue over time and across projects. . . 

=> OR... 
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Chapter 7 - GovSat 




• The previous discussion touched on XTCE's more complex areas 

- While nothing forces anyone to implement a full XTCE parser 

- Many have criticized some of its features as being overly complex, 
ambiguous, and too generalized 

• But this ignores the fact that each TLM/CMD community actually greatly differs in 
the details in many ways 

• I n addition, having each mission from scratch build XTCE rules guides 
specific to their mission is not ideal 

• Options? 

- limit the way XTCE can used for a certain community (not just a mission) 

- get broad agreement among various agencies in that community on these limiting 
rules 

- get the vendors that service that community onboard 

- (implied) limit aspects of tlrrVcmd architecture for space system 

GovSat 
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Chapter 7 - GovSat 



Universe of Possible XTCE Describabie 
Telemetry and Command Formats 

CCSDS Missions Non-CCSDS Missions 

GOVSAT Rules 


Although oriented towards CCSDS 
Many aspects applicable to any mission 


VJ 



J 
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Chapter 7 - GovSat 




• Agencies: 

- NASA/GSFC, ORS, Airforce, NRO 
Vendors or tools (agency): 

• ASI ST, ITOS, SI MMS (GSFC) 

• SRA I nternational/RI MMS (AF) 

• Harris/ OS- Comet (AF, NRO) 

• Specification: 

XTCE 1.1 - subsets XTCE using rules, but does not create a new schema 

• All GovSat files should validate with XTCE1.1 
Table of disallowed or allowed element and attributes 
Some allowed attributes are further restricted 

• Ex. Name length up to 64 chars 
Pattern for Commands and Packets 
Description Report 

Example DB 

• Version: 

1.0 Draft Revision available now! 

• Timeline: 

Tool vendors complete in Feb to March of 2010 

testing to commence in April, finalization of final 1.0 release by May to end of FY10 
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Chapter 7 - GovSat Specifics (Draft 1.0) 



• Of the —900 or so XTCE elements and attributes 

• (including elements and attributes with repeat or a re-used in the 
schema) 

• About —180 are completely disallowed 

• Of the remaining allowed elements, at least 20 are further restricted 

• Restricts manner in which packets and commands are described 
using Containers and Metacommand, and inheritance 

- Supports "GSFC-style" usage of CCSDS packet specs only 

• Other Major Items: 

• Lists specific set of ParameterTypes that are supported 

- Simplifies Time related ParameterTypes 

• Restricts calibrators and alarms 

• Restricts SpaceSystems 

• Restrict NameReferences 
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Chapter 7 - GovSat Restricts SpaceSystems 




• Only one SpaceSystem is legal 

- (thus Child SpaceSystems are illegal) 

• Legal (direct) Child elements of SpaceSystem 

- Header element required but details left to mission 

- Required: AncillaryData "FileType", “GovSat" 

- TelemetryMetaData 

- Command Meta Data 
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Chapter 7 - GovSat Restricts NameReferences 




• GovSat only allows one form: 

- Unqualified — just the name of the item of interest 

• no path information 

• Because there is only one SpaceSystem 

• @name items are global to document by "element type" 

- T aken together, the SpaceSystem restriction and @name 
globals: 

- Vastly simpler XTCE implementation 
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Chapter 7 - GovSat Restricts I nheritance 




• Even with one SpaceSystem and unqualified NameReferences 

- General XTCE inheritance still hard to implement 

• I nstead GovSat restricts XTCE inheritance to two specific patterns 

- TLM Packet Pattern 

- CMD and CMD Packet Pattern 

• There is an assumption that GovSat packets are: 

- CCSDS packets 

- And are used as NASA-GSFC missions use them 

• TLM secondary header is a time stamp on every packet 

• CMD side has no time stamp 

• Spacecraft I D, Virtual Channel I D, Application I D and packet length used to 
identify packets 

• And Appl D is unique and packet may appear on more than one VCI D 

(Not all CCSDS missions in fact use CCSDS packets as GSFC uses them) 
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Chapter 7 - Telemetry Packets Pattern 


& 


• CCSDSPacket Container (one) 

• Root for a 1 1 conta i ners 

• Contains the CCSDS fields and nothing else 

• Then CCSDSTelemetryPacket (one) extends CCSDSPacket 

• Adds no entries 

• Simply adds Restrictions (constraints) for telemetry flag check only 

• (supplied processing software COULD ignore these constructs entirely as 
they may represent baseline info that is simply a given) 

• Then each mission packet extends CCSDSTelemetryPacket 

- Supplies SCI D, VCI D, API D, packet length in Restriction Criteria 

- First entry is always time stamp 

- Container body is then filled in for the packet 

- These containers are considered final and may not be extended 

• Overall a very simple pattern that requires minimal implementation 


www.nasa.gov 


XTCE Tutorial, Manhattan Beach, California, March 3, 2010 


83 


Chapter 7 - GovSat Telemetry Packet Eample 




<xtce:SequenceContainer name="CAMONumlmagersReplyPacket"> 
<xtce:EntryList> 

<xtce:ParameterRefEntry parameterRef="TimeStamp"> 
<xtce:lncludeCondition> 

<xtce:Comparison value="1" parameterRef="CCSDSSecH'7> 
</xtce:lncludeCondition> 

</xtce : Para meterRef E ntry > 

<xtce:ParameterRefEntry parameterRef="CAM0Numlmagers7> 
</xtce:EntryList> 

<xtce:BaseContainer containerRef="CCSDSTelemetryPacket"> 

<xtce : Restri cti o n Cri te ri a > 

<xtce:ComparisonList> 

<xtce:Comparison value="42" parameterRef="CCSDSSCID7> 
<xtce:Comparison value="0" parameterRef="CCSDSVCID7> 
<xtce:Comparison value="2" parameterRef="CCSDSAPID"/> 
<xtce:Comparison value="8" parameterRef="CCSDSPacketLength7> 
</xtce:ComparisonList> 

</xtce : Restri cti o n C rite ri a > 

</xtce:BaseContainer> 

</xtce:SequenceContainer> 


Two Entries (if CCSDSSecH == 1) - plus header 
fields through inheritance (not shown) 

Four Comparisons in RestrictionCriteriaplus the 
one in CCSDSTelemetryPacket (not shown) 
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Chapter 7 - Commands and Command Packets 



• Command Pattern 

- Root CCSDSCommand 

- Has no arguments or any real content - an abstraction 

- Its CCSDSComnnand/ComnnandContainer is called CCSDSCommandPacket 

- Extends CCSDSPacket and checks the cmd flag in the header 

- Slightly irregular use of XTCE (but not too bad) 

- Specific Mission Commands extend CCSDSCommand 

- Provide cmd arguments, command complete verifier 

- Its Mission Command Packets extends CCSDSCommand/ CCSDSCommandPacket 

- Add entries 

- The mission command and packets are considered final and may not 
be extended 
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Chapter 7 - Command Example 



<xtce:MetaCommand name="CAMOGetlmagerlnfo"> 

<xtce:BaseMetaCommand metaCommandRef="CCSDSCommand7> 

<xtce:ArgumentList> 

<xtce:Argument argumentTypeRef="CAMOImagerNumberType" name="CAM0lmagerNumber7> 

</xtce:ArgumentList> 

<xtce:CommandContainer name="CAMOGetlmagerlnfoPacket" shortDescription="Get information for a specific imager"> 
<xtce:EntryList> 

<xtce:ArgumentRefEntry argumentRef="CAM0lmagerNumber7> 

</xtce:EntryList> 

<xtce:BaseContainer containerRef="CCSDSCommandPacket"> 

<xtce:RestrictionCriteria> 

<xtce:ComparisonList> 

<xtce:Comparison value="42" parameterRef="CCSDSSCID7> 

<xtce:Comparison value="0" parameterRef="CCSDSVCID7> 

<xtce:Comparison value="3" parameterRef="CCSDSAPID"/> 

<xtce:Comparison value="1 " parameterRef="CCSDSPacketLength7> 

</xtce:ComparisonList> 

</xtce : Restri cti o n C ri te ri a > 

</xtce:BaseContainer> 

</xtce:CommandContainer> 

</xtce:MetaCommand> 


Command and its Packet 
-CAMOGetlmagerlnfo 

--CAMOGetlmagerlnfoPacket 

One argument, & header entries (not 
shown) 

-CAMOImagerNumber 

Four Comparisons (plus one in 
CCSDSCommandPacket not shown) 
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Chapter 7 - Draft Release 


& 


• Draft Release Contains 

• Presentations (explanatory) 

• Documentation - report describing GovSat rules 

• Rules - the rules table 

• Example - a full and realistic example 
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Backups 
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Chapter 8 - A Quick Look at J AXB 



• J AXB - J ava Architecture for XML Binding 

- Will map your XML Schema (i.e. XTCE) to J ava Classes 

• Has additional features including "binding" configuration file 

• Used to implement most of GSFC XTCE prototype software 

- Plusses: 

• J ava Generics and Collections well supported 

• Mapping tunable w/config file 

• Now part of official distribution 

Everyone has it that downloads J ava 

• Some support for DOM nodes 

But not built on DOM (that I can tell!) 

• ...? 

- Misses: 

• Can't seem to parse or build comments 

• Can't convert any unmarshalled object to a DOM node 

But seem to be able convert any DOM node to a marshalled object 

• a 7 
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Chapter 8 - J AXB SchemaTypes to J ava Mapping 



XML Schema DataType -> Mapping to Java Type or Class 

(some) 


Examples 

xsd:string -> java. lang. String 
xsd:integer -> java. math. Biglnteger 

xsd:dateTime -> javax.xml.dataType.XMLGregorianCaledar 

xsd:double -> double 

Etc... 
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Chapter 8 - J AXB Ex. XTCE SchemaType to J ava 



XTCE SpaceSystemType 


XTCE SpaceSystemType Java Class 


<complexType name="SpaceSystemType" mixed="false"> 
<complexContent mixed="false"> 

<extension base="xtce:NameDescriptionType"> 

<sequence> 

<element name="Header" type="xtce:HeaderType" 
minOccurs="0"/> 

<element name="T elemetryMetaData" 

type="xtce:TelemetryMetaDataType" minOccurs="0"/> 
<element name="CommandMetaData" 

type="xtce:CommandMetaDataType" minOccurs="0"/> 
<element name="ServiceSet" minOccurs="0"> 
<complexType> 

<sequence> 

<element name="Service" type="xtce:ServiceType" 
maxOccurs="unbounded'7> 

</sequence> 

</complexType> 

</element> 

<element ref="xtce:SpaceSystem" 

minOccurs="0" maxOccurs="unbounded"/> 
</sequence> 

<attribute name="operationalStatus" 

type="token" use="optional"/> 

</extension> 

</complexContent> 

</complexType> 



public class SpaceSystemType extends NameDescriptionType 
{ 

protected HeaderType header; 

protected TelemetryMetaDataType telemetryMetaData; 

protected CommandMetaDataType commandMetaData; 

protected SpaceSystemType. ServiceSet serviceSet; 

protected List<SpaceSystemType> spaceSystem; 

protected String operationalStatus; 

public HeaderType getHeader() { return header;} 

public void setHeader(HeaderType value) { this. header = value;} 

public boolean isSetHeader() { return (this.header!= null);} 

public TelemetryMetaDataType getTelemetryMetaData() { 
return telemetryMetaData; 

} 

public void setTelemetryMetaData(TelemetryMetaDataType value) { 
this.telemetryMetaData = value; 

} 

public boolean isSetTelemetryMetaData() { 
return (this.telemetryMetaData!= null); 

} 

public CommandMetaDataType getCommandMetaData() { 
return commandMetaData; 

} 

public void setCommandMetaData(CommandMetaDataType value) { 
this. commandMetaData = value; 

} 

public boolean isSetCommandMetaData() { 
return (this.commandMetaData!= null); 

} 


H ... DELETED FOR SPACE REASONS 

} 


Note: items edited to fit. . . . 
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Chapter 8 - Simple J AXB XTCE Example 



import javax.xml.bind.JAXBContext; 
import javax.xml. bind. JAXBEIement; 
import javax.xml. bind. Marshaller; 
import org.omg.space.xtce.ObjectFactory; 
import org.omg.space.xtce.SpaceSystemType; 


public class SimpleSpaceSystem { 


public static void main(String[] args) { 
JAXBEIement<SpaceSystemT ype> spaceRoot; 
JAXBContext jc; 

Marshaller marshaller; 

ObjectFactory factory; 

try { 

jc = JAXBContext.newlnstanceforg.omg.space.xtce"); 
marshaller = jc.createMarshaller(); 
marshaller. 
setProperty( 

"com.sun.xml. internal. bind. namespacePrefixMapper", 
new XTCEPrefixMapper()); 



<?xml version="1 .0" encoding="UTF-8" standalone="yes"?> 
<xtce:SpaceSystem xmlns:xtce="http://www.omg.org/space/xtce" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
name="HelloWorld" 
xsi:schemaLocation= 

"http://www.omg.org/space/xtce SpaceSystemVI .1 ,xsd"/> 


marshaller. 

setProperty(Marshaller.JAXB_SCHEMA_LOCATION, 

"http://www.omg.org/space/xtce SpaceSystemVI .1 .xsd"); 
marshaller. 

setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, 
new Boolean(true)); 
factory = new ObjectFactory(); 

SpaceSystemType space = factory. createSpaceSystemType(); 

space.setName("HelloWorld"); 

spaceRoot = factory. createSpaceSystem(space); 

marshaller.marshal(spaceRoot, System. out); 

> ca,ch (Exception e) { e.printStackTrace(); } Note: XTCEPrefixMapper not shown 
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Chapter 7 - Harder XTCE I terns to I mplement 



• General NameReferences and NameReference I nstances 

- All "refs" should point to something valid: you must implement this 

- Absolute addresses: /a/ b/c and various forms of relative addresses: ../b/c, a/../b, 
etc. . . 

- "Path- less" nameRefs which may involve a partial tree search: c 

- Instances: Adds array syntax: / c[l]. And aggregate syntax: /a/b/c.subField 

• And relates to some sort of "instance table" 

• Container I nheritance, EntryList, I ncludeConditions, etc... 

- Various general aspects of inheritance, EntryList addressing 

• Multiple levels, containerRefs that themselves have inheritance, and so on 

• XTCE Type I nheritance 

• Dynamic Container Match & NextContainer 

Never been implemented yet that we are aware of. . . 

(a few more not mentioned) 


But wait, I have to implement all of those? Depends... 
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Chapter 7 - Native I mplementation 




• An implementation that uses XTCE internal to a toolchain 

- Gets packet stream on input, uses XTCE to pull-apart into host-side 
telemetry items 

- Or build cmds for uplink using definitions to supply args, values & format 

• High degree of automation or self-configuration possible 

- Possibly implement every feature of XTCE 

• Thus potentially ingesting ANY XTCE file that is correct to self-configure 
software for any incoming data stream 

But of course one can always constrain or restrict XTCE support if necessary 

• I implementations? 

- Some aspects of GSFC prototype software falls into this category. . . 

But never used to actually decommutate binary packet data (yet) 

University of Bremen (Germany) implementation used XTCE to configure itself for decommutating 
binary packet file 

• Demo'd . . . but source? 
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Chapter 7 - Exchange I mplementations 



• 100% XTCE Exchange between teams using same features 

- Agreement ahead of time on which features of XTCE to use 

- Depends somewhat on hardware of team members 

• If controlled or standardized between members: 100% exchange possible 

• As these agreement don't exist, 100% exchange is not possible without 
COMMON AGREEMENTS 

Ex. Extreme case: I support only telemetry, you support only Commands. Our XTCE files are 
100% incompatible! 

- But even differing formats may offer partial exchange 

• NASA CCSDS & ESA PUS Mission were able to exchange the majority of telemetry metadata 
even though basic packet formats ultimately differ... but it took some work 

• I mplementations? 

- GSFC J WST Translator 

- CNES "Best" Suite 

- ESA Cryosat. . . 

- Several others. . . mostly on the "Customer" side - (NASAs of the world) 
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Chapter 7 - I ngredients in Successful Exchange 



• Now: 

Determine exchangees (team members), agree on common "flavor" of XTCE features 

• Future: 

I ndustry agreed upon flavors, pick the category you fall into... 

• Develop common XTCE usage “constraints" to format 

- CCSDS is a "format" but stops at the header 

- You have to get down deeper Examples: 

• Polynomials, # of coefficients 

• Alarm levels 

• Floating point sizes and formats 

• Bit/ byte orderi ng . . . 

• Etc..., etc..., etc... 


• I mplement to these constraints & 100% exchange is possible between team 
members, institutions, and so forth 
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Chapter 7 - Automating Exchange? 


& 


• Write XTCE constraints in a computer processable manner 

• Process constraints to configure validation software 

- Use in conjunction with XML Parsing to validate XML in "your" XTCE 

• Process constraints to configure "XTCE builder" software 

- An API that only allows XTCE files to be constructed in "your" flavor 

• Are all constraints describable in a computer processable 

manner? 

??? 

■ ■ ■ 

• I s this an additional area of standardization? 
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